home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Collection of Tools & Utilities
/
Collection of Tools and Utilities.iso
/
comm
/
mpmod160.zip
/
MPMODEM.DOC
< prev
next >
Wrap
Text File
|
1994-01-01
|
117KB
|
2,638 lines
MPModem v1.60
Implements Xmodem, Ymodem &
Zmodem all in one package.
Includes many custom enhancements
like Fast transmissions, Compressed
transmissions and large block
transfers.
(C) Copyright
All rights Reserved.
Mark Jose
This manual is Copyright (C) to M. Jose.
MPModem v1.60 Copyright (C) M. Jose Page 1
Table of Contents
-----------------
1.0 Terms and Conditions of use ................................ 2
1.1 Disclaimer ................................................. 3
1.2 License agreement .......................................... 3
2.0 MPModem: What does it do? .................................. 4
2.1 The MPModem Screen ......................................... 6
3.0 What equipment do I need? .................................. 10
3.1 Configuring MPModem with MPConfig .......................... 10
3.1.1 File Transfer Options Screen ............................ 11
3.1.2 General Setup Options Screen ............................ 16
3.1.3 Modem/Port Options ...................................... 19
3.1.4 Communication Port Addresses ............................ 21
3.1.5 Miscellaneous Items ..................................... 22
3.1.6 Screen & Colours Setup .................................. 24
3.1.7 Save Configuration ...................................... 25
4.0 Running MPModem from DOS ................................... 26
4.0.1 BBS Users ............................................... 30
5.0 File Formats ............................................... 32
5.0.1 Input File .............................................. 32
5.0.2 Log file format ......................................... 32
5.0.3 Report file format ...................................... 33
6.0 Future Enhancements ........................................ 34
7.0 Messages ................................................... 35
7.0.1 System Messages ......................................... 35
7.0.2 Report File Messages .................................... 48
8.0 Exit Codes ................................................. 50
9.0 Running MPModem from a Bulletin Board ...................... 52
9.0.1 Reading the log file to obtain transfer details ......... 54
10.0 Executing commands with Zmodem ............................. 55
11.0 Acknowledgements ........................................... 56
MPModem v1.60 Copyright (C) M. Jose Page 2
1.0 Terms and Conditions of Use.
---------------------------------
This program is freeware and as such the author retains full
copyright over the contents of this file, all files written by the
author and the format of files generated by the programs
MPModem.Exe, MPConfig.Exe, and Cfg-Conv.Exe. This includes the
configuration file (MPModem.Cfg), the log file (MPModem.Log), the
report file (MPModem.Rpt) and any other files other than files
transmitted through this program. (1)
The author encourages you to distribute this program to any person
or persons you wish so long as the contents thereof are unaltered
in any way other than the form of archiver or compressor used. The
author supports the use of the LHA group of compressors and
archivers. See "License agreement" for more details and specifics.
Any source is provided free of charge. You may use the source code
within your own programs SO LONG as you include that source as part
of the distribution of your program, just like MPModem has done.
You may make changes to the source code and redistribute, so long
as you keep any existing copyright notices intact. Please annotate
where appropriate.
You MAY NOT use the source code in your programs WITHOUT including
the source with the distribution containing your program. The
reason is simply to allow others to use the code and therefore
everyone benefits. Failure to adhere to this simple rule means you
CANNOT use the source code or any derivative thereof in your
programs. To do so is to violate international copyright
conventions.
----------
(1) In other words, any files you send or receive using any of the
protocols contained within MPModem are (of course) copyright of their
respective owners and as such cannot be copyright to me. Any other
files created by MPModem and related programs for statistical and or
control purposes are the copyright property of the author.
MPModem v1.60 Copyright (C) M. Jose Page 3
1.1 Disclaimer
---------------
This product is provided to you "as is". There is no warranty
either expressed or implied applicable to this program or any other
utility or program produced by the author. Use of this program is
at your own risk and as such the author is not liable for any
damages or loss of profits resulting either directly or indirectly
from your ability to correctly or incorrectly use the said
products.
The author makes no warranty that this program and all associated
programs are fit for any particular purpose. Any implied warranty
of merchantability is expressely and specifically denied.
By using this program, its associated programs and documentation
you agree to the above conditions as outlined in sections 1.0 and
1.1 respectively.
1.2 License agreement
----------------------
You are granted a license to use this product for whatever reason
you see fit. Under no circumstances do you own this product.
Although it is free to you, it is NOT Public Domain - it is
copyrighted by Mark Jose and shall remain so.
You may distribute this program in unmodified form which includes
all programs, documentation, data and other files.
You may not include the product with any other product for any
reason whatsoever and you may not charge or elicit payment of any
kind for the copying or transfer of this program for other people
to evaluate other than to recoup the costs of the media that
contains this product.
There are exclusions to this:
If you first contact me, I MAY allow you to include this
program with other packages like CD-ROM software
collections and so on. In which case, terms can be
negotiated.
All Bulletin Board operators may allow the downloading of this
product providing the Bulletin Board is not engaged in trading for
profit and/or repackaging software in any form other than the
original form of this product and all its accompanying articles and
products and is not charging users of their Bulletin Board(s) a
specific fee to download this product.
MPModem v1.60 Copyright (C) M. Jose Page 4
2.0 MPModem: What does it do?
------------------------------
MPModem implements 3 main protocols, these being Xmodem, Ymodem and
Zmodem. It also implements a further derivative of Xmodem, Xmodem
with 1024 byte blocks (the normal is 128 bytes) as well as
Ymodem-G, a full streaming non-error-correcting protocol derived
from Ymodem.
The implementation of Ymodem is not just simply Xmodem with 1k
(1024 byte) blocks and a filename header but rather it is the
"real" Ymodem which can take varying sized (128/1024 byte) blocks,
transfer files without padding and preserves the file date and
time.
Zmodem is the "evolution" of X/Ymodem to a more flexible protocol.
It has the ability to resume a previously aborted transfer and is
very rigid when dealing with noisy lines (though not perfect). It
also supports Fast-style file transfers, large block transfers and
compression.
My implementation of Zmodem is the same as that of other authors of
Zmodem with the major exception that it allows the transfer of
files from systems like the Macintosh (tm), Apple (tm), Unix (tm),
BSD (and its various connotations) without causing problems with
filenames and MacBinary headers (when it is a MFS). This system is
called "Filename Integration" and is copyrighted by me.
I have also implemented my own version (non-copyrighted) of a very
basic compression routine first used by Richard B. Johnson in his
program Jmodem as well as a Fast mode transfer based on PC²'s
"Turbo" transfer. The difference between mine and PC²'s version is
that mine does not use variable length headers which are
copyrighted to Chuck Forsberg.
This version incorporates larger block sizes than normal Zmodems.
This is loosely based on the "ZedZap protocol" which allows for
Fido-style mailers to transfer Zmodem blocks of up to 8192 bytes
(as against the norm of 1024). This process is rather clumsy in
that it just increases the size of the blocks until it either
receives an error or reaches its maximum blocksize of 8192 bytes.
My system uses a much better way (in my opinion) which allows the
sender and receiver to negotiate the ability to transmit large
blocks and then defaults to a maximum block size of 4096 bytes.
MPModem uses fully buffered interrupt driven serial output and
input for optimum throughput and is optimised to give you the very
best in protocol handling. It uses a minimum of memory and will run
quite well in less than 100k of memory (providing you don't use a
large disk buffers and large block transfers).
It is optimised to work well under Desqview (tm) and has built in
facilities to change the method of screen writing (for the benefit
of other less well behaved multi-taskers), to set larger disk read/
write buffers and larger/smaller communications I/O buffers.
MPModem v1.60 Copyright (C) M. Jose Page 5
This page intentionally
left blank.
MPModem v1.60 Copyright (C) M. Jose Page 6
2.1 The MPModem Screen.
------------------------
┌─────────────────────────────────────────────────────────────────────┐
│ Zmodem Receive (1) │
├─────────────────────────────────────────────────────────────────┬───┤
│ Pathname: (2) │CAR│(26)
│ Filename: (3) ├───┤
│ │BIN│(27)
│ Check Type : CRC-16 (4) Blocks Expected: (9) ├───┤
│ Error Count : (5) Blocks Received: (10) │FST│(28)
│ Last Frame : (6) Approx. Cps : (11) ├───┤
│ │CMP│(29)
│ Transfer Time: (7) Bytes Expected : (12) ├───┤
│ Elapsed Time : (8) Bytes Received : (13) │LOG│(30)
│ ├───┤
│ Messages: │MOD│(31)
│ Initialising file transfer. (14) ├───┤
(15)│ (16) (17) (18) (19) (20) (21) (22)│KIL│(32)
├───────────┬───────┬────────┬────┬────┬───────────────────────┬──┼───┤
│RX: │Port: 1│FIFO: 4│ │ │Space: 133447936 bytes│ 5│BIG│(33)
├───────────┴───────┴────────┴────┴────┴───────────────────────┴──┴───┤
│ Version 1.60 MPModem (C) Copyright 1993 M. Jose │
├──────────────────────────────────────┬──────────────┬───────────────┤
(23)│ │ Baud: 19200 │Time on : 0 │
└──────────────────────────────────────┴──────────────┴───────────────┘
(24) (25)
(1) The type of transfer about to take place.
(2) The "Pathname" is the path to the upload or download
directory.
(3) The "Filename" is the name of the file currently being
received or sent.
(4) "Check Type" is the type of block checking that is relevant
to the particular transfer type you have selected. With
Zmodem the type of checking is either CRC-16 or CRC-32. With
Xmodem and or Ymodem the checking is either checksum or
CRC-16.
(5) "Error Count" is the total number of errors so far
encountered while performing this file transfer. If Zmodem
reaches about 14 errors it will abort.
(6) "Last Frame" is only relevant to Zmodem. This basically
displays the last packet type that was received by Zmodem.
This field will display "Transfer Time" if you are
receiving/downloading a file and will display "Time Left" if
you are sending/uploading a file.
(8) "Elapsed Time" is the total amount of time so far taken to
receive or send the file.
MPModem v1.60 Copyright (C) M. Jose Page 7
(9) This field displays "Blocks Expected" when
receiving/downloading files or "Blocks To Send" when
sending/uploading files. This field is only used when
sending with Xmodem or Ymodem and receiving files with
Ymodem.
(10) This field displays "Blocks Received" when
receiving/downloading files or "Blocks Sent" when
sending/uploading files. This field is used when sending or
receiving using Xmodem or Ymodem protocols.
(11) "Approx. Cps" is an approximate Characters Per Second rate
when transferring files. Please note that because of
internal buffering when tsending files, the CPS rate may
seem too high for the baud rate selected.
(12) This field displays either "Bytes Expected" when
receiving/downloading files or "Bytes To Send" when
sending/uploading files. When sending files with any
protocol this will always contain the size of the file
regardless of the protocol used. When receiving files, an
amount will only be shown if you are using Ymodem or Zmodem.
(13) This field displays either "Bytes Received" when
receiving/downloading files or "Bytes Sent" when
sending/uploading files. An amount of bytes will be shown as
the file transfer progresses to show how far the file
transfer has progressed.
(14) This field displays any error and system messages.
(15) Directly under the error and system messages field is the
warning message area. Generally this is only used to show
the filename that was transmitted before converting the
filename to DOS format. (See the "-m" switch).
(16) This box will contain the remote's version number if the
remote program sends this information. MPModem sends and
receives this information. The ability to do so will also
enable future features.
(17) This box contains the current port number you are running
MPModem off. Be aware that what you set as the port number
in the configuration program (MpConfig) will override the
port specified on the command line with the "-p" option.
(18) This box will tell you if your UART chip has a FIFO buffer
and if so it will display the number of bytes that will be
buffered. If no chip is present or you have turned off this
feature via the MpConfig program, then "NO" will appear.
(19)
This is the current block or packet size of the transfer.
With Xmodem it is always 128 (bytes), with Xmodem-1k it is
always 1024, with Ymodem and Ymodem-G it can be 128 and/or
1024, and with Zmodem it can be from 32 to 1024 bytes.
MPModem v1.60 Copyright (C) M. Jose Page 8
(20) This is the compressed block size. This will only display
when both you and the remote have activate compression.
(21) This is the current amount of free bytes left on the disk
where the receival of the file is going to. It is not
perfectly accurate until the whole file has been received
since it does not take into account the amount of disk space
taken for directory entries etc. It is merely there to give
you an indication of disk space. If you use a multi-tasker
then the figure may be wrong until the next file is started
and a physical read of disk space takes place.
(22) This is the current time out value in seconds. This time
dictates how long the transmitter or receiver routines will
wait before giving up and issuing an error message.
(23) This field can contain the name of the current user (if you
are a BBS operator) or the name of the current system you
are connected to. To have this information displayed, you
must pass it to the program using the "-v" switch. Refer to
the reference to "-v" later in this documentation.
(24) This field displays the terminal speed of the program. With
high speed modems (that use compression to "cheat"), this
value will differ from the actual modem to modem speed (also
known as the carrier speed). This baud rate is commonly
called the connect rate.
(25) This field displays the amount of time left of the current
user (if you are running a BBS) or the amount of time you
have been online to the remote host. Some terminal programs
allow you to pass to this program the amount of time you
have been online. MpModem will then continue to display the
time expended. To have this displayed you need to specify
the "-t" switch. Refer to the documentation for more
details.
(26) If "CAR" appears this means that the carrier is currently
being monitored. This means that as soon as the carrier is
found to have been lost the program will finish the
transfer. To activate this option, select the "-c" command
line switch. (See "-c" for more information).
(27) If "BIN" appears this means that the current Zmodem (only)
transfers is being transferred in binary mode. To override
this (keeping in mind the ramifications of such action), you
may specify the "-a" switch on the command line. (See "-a"
for more information).
(28) If we are running in fast mode then it will contain the
letters "FST". This mode of transmission does not escape
special characters that the traditional Zmodem will do. In
this case, the transmission has less overhead. The actual
speed increase depends very much on what is in the file.
Files full of Telnet escape characters will be dramatically
faster if sent using this method.
MPModem v1.60 Copyright (C) M. Jose Page 9
(29) When a transmission is to be made while trying to compress
the data, this box will contain the letters "CMP". MPModem
will only ever send a compressed packet when the compressed
length of the block of data is less than the uncompressed
block of data.
(30) If "LOG" appears in this frame then the current transfer is
being logged to the file "MPMODEM.LOG". To enable this
function, ensure that the option "Always log file
transfers?" in the "File Transfer Options" section of the
MpConfig program is set to "Y".
This is MANDATORY for sysops - unless of course they don't
like to keep track of what files the users send and receive!
(31) If "MOD" is displayed this means that ALL incoming files are
checked and modified to DOS standards. This is handy when
transferring files from a Macintosh or other "strange"
naming convention site. (See "-m" for more details).
(32) If "KIL" appears in this box while receiving a file then
this means that if the transfer is aborted and the file not
properly recieved then that file will be deleted. If it
appears while sending then this indicates that after the
successful completion of the transfer, this file will be
deleted off your disk.
(33) When this box displays "BIG", both you and the remote end
have invoked MPModem with "-l" which allows you to transmit
and receive blocks of up to 4096 bytes (rather than 1024).
MPModem v1.60 Copyright (C) M. Jose Page 10
3.0 What equipment do I need?
------------------------------
You need the bare minimum configuration of PC equipment which
comprises a PC, PC/XT, PC/AT, PS2 and so on up the scale.
The program takes up about 80k with an additional 10k after
startup. That means around about 90k in total. If you increase the
size of the disk read/write and/or communications buffer, then you
will also increase the overall memory usage.
Likewise, if you are running a Zmodem session and using large
blocks (via the "-l" switch) then the overall memory requirements
increase by about 10k. Keep in mind that this amount of memory is
used IRREGARDLESS of whether the remote end can send or receive
with large blocks.
A safe memory amount would be about a minimum of 256k or much more
if you are running this from a BBS. As well you will require a
COM1: to COM8: serial port(s) which use an 8250, 16450, 16550 or
similar chip.
3.1 Configuring MPModem with MPConfig
--------------------------------------
In order to streamline the usage of MPModem, there is a facility
available to preconfigure MPModem using a program called MPConfig.
This program allows you set most "options" and thus never have to
change them during the normal course of running the program.
Open invoking MPConfig, you are presented with a screen:
╔═══╡ Configuration Menu ╞═══╗
║ ║
║ File Transfer Options ║
║ General Setup Options ║
║ Modem/Port Options ║
║ Com. Port Addresses ║
║ Miscellaneous Items ║
║ Screen & Colours Setup ║
║ Save Configuration ║
║ ║
║ ║
╠════════════════════════════╣
║ MPModem ║
║ Copyright (c) 1993 v2.1 ║
║ M. Jose ║
╚════════════════════════════╝
This is the "master menu". Here you select the option you would
like by pressing the Up or Down arrow keys. Once the menu bar (it
will highlight the text) is over the required option, press the
[Enter] key to enter that sub menu.
MPModem v1.60 Copyright (C) M. Jose Page 11
3.1.1 File Transfer Options Screen
-----------------------------------
The following is the screen which is displayed when you select the
"File Transfer Options" off the master menu:
╔═══════════════════════════╡File Transfer Options╞══════════════════╗
║ ║
║ Always monitor Carrier during transfers?............. Y ║
║ Delete a failed transfer? (Receiving).............. N ║
║ Allow remote to execute programs/commands?........... N ║
║ Use CTS/RTS hardware flow control?................... N ║
║ Delete file after transfer? (Sending)............... N ║
║ Always log file transfers?........................... Y ║
║ Modify filenames when receiving files?............... N ║
║ Generate timeout values according to Baud rates?..... Y ║
║ Use BIOS when writing to the screen?................. N ║
║ Force the sender to resume if necessary?............. N ║
║ Force the sender to resume with CRC check?........... N ║
║ Run this program from a BBS?......................... N ║
║ Allow creation of a unique name? (BBS only).......... N ║
║ Always Escape all control characters? (Zmodem only).. N ║
║ Use current Comm. port settings for Baud rate?....... N ║
║ ║
║ ║
║ ║
║Watch for Modem Hangup, dropped lines etc. ║
╟────────────────────────────────────────────────────────────────────╢
║Esc: Exit, : Move MPModem Configuration Copyri║
╚════════════════════════════════════════════════════════════════════╝
Now follows an explanation of all the configuration questions.
Always Monitor Carrier during transfers?
Selecting "Y" will result in MPModem quitting the current
transfer if it detects the loss of carrier. For those modems
that do not force carrier high, do not use this switch but
rely on the "timing" capabilities of the program to know when
a connection is lost. That is, continual timeouts by
X/Y/Zmodem will cause it to abort. (See Timeout for more
details).
If you only want to occasionally monitor carrier, then do not
annswer Y here but specify "-c" on the command line when you
want to monitor carrier.
Delete a failed transfer? (Receiving)
If you answer "Y" to this question, MPModem will DELETE any
failed transfer. This option is especially useful for BBS
operators who do not want their disk crowded with partially
received files.
The default is 'N'.
MPModem v1.60 Copyright (C) M. Jose Page 12
Allow remote to execute programs/commands?
Answering "Y" will allow Zmodem to receive commands from the
receiver requesting that certain commands be done. For
example, MPModem can be made to execute another program or
even run a batch file. It can be made to execute a command
and then return back to the program or it can be made to
overwrite the current program in memory with another program
specified by the remote.
This is a potentially powerful and dangerous option and
should only be activated when you have 100% confidence in the
remote user.
It executes the unix command of "SH.EXE" for shell. If you
want the equivalent for DOS then check your local BBS for
one and rename it as "SH.EXE" and place it in your MPModem
directory.
The default is 'N'.
Use CTS/RTS hardware flow control?
Answer "Y" here to use CTS/RTS flow control. Originally this
type of control was designed for half-duplex modems where
the change in signal would cause the modem to swap from
being a receiver to being a transmitter. Now it is more
commonly used with speed buffered modems (with say, a
connect rate of 9600 and a DTE rate of 19200).
To prevent the modem from skipping data, the modem's RTS
pin's voltage is lowered to tell the local DTE that we must
pause, until RTS is again asserted, before sending any more
data.
If you have speed buffering, MNP or LAP/M then make sure
CTS/RTS flow control is enable on the modem and also through
the program.
The default is 'N'.
Delete file after transfer? (Sending)
Answering 'Y' will mean that after each successful SENDING
of a file, that file will be deleted off your disk. This is
especially handy for people who are sending one off files
that are no longer needed on the host machine.
The default is 'N'.
MPModem v1.60 Copyright (C) M. Jose Page 13
Always log file transfers?
It is suggested that you leave this as 'Y' (Log always on)
as important information is placed in the log. For Sysops,
it is MANDATORY in order for their supported board to work
properly.
The default is 'Y'.
Modify filenames when receiving files?
If you are always receiving files from a Macintosh source or
you are a Sysop who thinks he may receive files from a
Macintosh source, then answer 'Y' to this question.
For example, a file transferred from a Macintosh (tm)
machine may be called:
Some Macpaint Pics.cpt
with this switch active, the filename would be converted to:
Some_Mac.cpt.
Although this option is only really useful when transferring
files from a Macintosh (R) system to DOS you should still
answer "Y" here just in case you ever receive a file from a
Macintosh user.
Any non-standard MS/PC Dos format (even Unix and Amiga) will
be converted to DOS format.
The default is 'N'.
Generate timeout values according to Baud rates?
Answering "Y" to this question will make MPModem calculate
the value (in seconds) required for timeout handling
according to the BPS rate (not the BAUD rate). Thus the
faster the connection speed the shorter the timeout value.
The absolute minimum timeout value is 5 seconds and the
maximum is around 50 seconds for a 300 BPS connection.
MPModem v1.60 Copyright (C) M. Jose Page 14
Use BIOS when writing to the screen?
Answer "Y" to this if you are always running under a
multi-tasking/ multi-window environment where
"bleed-through" is not desirable. Although the screen writes
are some degree slower if you answer "Y", it is better than
"bleed-through" to the other screen if you answer "N".
If running Desqview then you may use "Y" for direct screen
writes as this program is very well behaved when used with
Desqview and it will speed up screen writing.
The default is 'N'.
Force the sender to resume if necessary?
This affects Zmodem file transfers only!
This is the same as the "-y" switch. IF you are running a
BBS then make sure that you answer 'N' to this question. To
all other users, it is recommended that if you receive files
from a Macintosh system where the filename is renamed that
you also answer 'N'. The reason why is:
Suppose you want to receive two files from a Macintosh
system called "GeneralText.Word" (size 25067) bytes and
another file called "GeneralTestAns.Word" (size 15460)
bytes. With the "-m" switch specified the first filename
will be renamed as "GENERALT.WOR". When you receive the
second filename, it too will be renamed to
"GENERALT.WOR". If you force the sender to resume, it
will try to resume at 25067 bytes (the original size of
"GeneralText.Word"). As you can see this is past the
total file size of the incoming file
"GeneralTestAns.Word". Improperly written Zmodem drivers
will seize up at this and at the very least the first
file "GeneralText.Word" will be truncated and
overwritten.
Generally, the author encourages ALL users to leave this
switch as 'N' unless they are absolutely certain they
realise the consequences of their actions.
Force the sender to resume with CRC check?
BLANK.
Run this program from a BBS?
This switch is the same as the "-!" switch. Answer 'Y' to
this question if and only if you are running this program
from a BBS such as RemoteAccess. The default is 'N'.
MPModem v1.60 Copyright (C) M. Jose Page 15
Allow creation of a unique name? (BBS only)
When receiving files it is sometimes necessary to create a
unique filename if the incoming file has the same name as an
existing file.
For example, suppose we had a file called "frednurk.zip". If
the incoming file is "frednurk.zip" but is a different size
than the "frednurk.zip" we have on our system then the
incoming file is received as "frednurk.zi1".
Under normal circumstances this is not desirable when
running under a BBS as this would allow people to upload a
file that is already in existance.
The default is "N".
Always Escape all control characters? (Zmodem only)
If you are to use Zmodem to send to a remote site through a
network that does not accept the full IBM character set of 0
to 255 decimal, and thus only supports A-Z, a-z and
characters like %$#@!*&^, then answer "Y" to this question.
This will cause all control characters and extended ascii
characters to be converted to a character acceptable by the
network or computer you are sending to or receiving from.
Using this method will cause the program to run slower as it
has to encode such characters which adds 50% to the overhead
of the program.
Use current Comm. port settings for Baud rate?
Answer "Y" to this if you are running MPModem under a BBS or
some program that does not report the actual connect rate.
Some BBS (like RemoteAccess) report only the carrier speed
which may differ if speed buffering for MNP or LAP/M is
active. For example, you may connect with a CARRIER speed of
9600 but a CONNECT speed of 19200. MPModem requires the
CONNECT speed rather than the CARRIER speed.
If you are having trouble running MPModem - when you select
it you get garbage appear on the screen - then answering "Y"
to this option will rectify the problem (if it has to do
with invalid BAUD rates!)
MPModem v1.60 Copyright (C) M. Jose Page 16
3.1.2 General Setup Options Screen
-----------------------------------
The following is the screen which is displayed when you select the
"General Setup Options" off the master menu:
╔═══════════════════════════╡General Setup Options╞══════════════════╗
║ ║
║ Enter size of Disk I/O Buffer. (1 to 20k) 1 ║
║ Enter size of Receive Communications buffer. (1 to 20k) 2 ║
║ Enter size of Transmit Communications buffer. (1 to 20k) 1 ║
║ If running from a BBS, enter port number. (1 to 8) 0 ║
║ Wait for user to ACK. (32 to 1024 bytes) 0 ║
║ Use sub-packets. (24 to 1024 bytes) 0 ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║The larger the buffer the less disk writes per transfer. ║
╟────────────────────────────────────────────────────────────────────╢
║Esc: Exit, : Move MPModem Configuration Copyri║
╚════════════════════════════════════════════════════════════════════╝
Enter size of Disk I/O Buffer. (1 to 20k)
This allows you to specify the Disk Read/Write buffer.
Specifying a buffer of around 2 to 4 will decrease the
amount of disk writes. When running a multi-tasking and/or
multi-line BBS and you have plenty of memory to spare set
the buffer at anything from 10 upwards.
Be aware that should your system freeze or "collapse" in
some way, any bytes yet to be written to disk WILL BE LOST!!
MPModem v1.60 Copyright (C) M. Jose Page 17
Enter size of Receive Communications buffer. (1 to 20k)
This option lets you set the receive communications buffer
size as used by the internal interrupt routines of MPModem.
The optimum setting is around 2 (2k or 2048 bytes) but you
may find your system runs better with a larger buffer of say
4 (4k or 4096 bytes). Generally the latter is the case if
you are running under a multi-tasker and are doing some
intensive work in one of "windows".
If you experience CRC errors and the like when receiving
using Zmodem, then try setting the buffer higher. The reason
you are getting these errors is your machine just isn't
coping too well with all the strain. (Poor thing...)
Enter size of Transmit Communications buffer. (1 to 20k)
This option allows you to modify the transmit buffer used by
the internal transmit routines of MpModem. Generally there
will be no reason to change this buffer, but if you wish the
option is there for you.
I have experienced problems with some modems not liking a
big buffer when transferring only a small file. For example,
if you have a Transmit buffer of 4k but your file is only
3k, a couple of modems have trouble. The result is Zmodem
has to wait for a timeout before trying to end the transfer.
If you set a big buffer and this occurs then you are best to
go back to a smaller buffer. 1k (or 1024 bytes) is the
default.
If running from a BBS, enter port number. (1 or 2)
This is the same as specifying "-p{portno}" on the command
line. If you enter a port in here, this port will ALWAYS be
used regardless of what your communication or BBS program
passes to MPModem. Use this wisely.
Wait for user to ACK. (32 to 1024 bytes)
Entering a number in here (from 32 to 1024) will cause
Zmodem to work just like an ACK-type protocol such as
Xmodem.
What this does is cause Zmodem to create "frames" of the
size you specify to be sent before an ACK is required to be
sent by the remote system. For example, 512 will result in
an ACK being sent after every 512 bytes.
If you do not wish to run Zmodem as an ACKed protocol, and
thus as a full streaming protocol, then do not enter a
number in here.
MPModem v1.60 Copyright (C) M. Jose Page 18
Use sub-packets. (24 to 1024 bytes)
Entering a number (from 24 to 1024) in here will cause
Zmodem to use sub-packets of a certain length. For example,
256 will result in sub-packets of 256 bytes being sent.
Specifying a number is especially useful if you expect the
transfers to take place under noisy conditions where
error-recovery is optimised by sending smaller packets.
The tradeoff, however, is a higher overhead as smaller
packets require more data to be "wrapped around them" such
as CRC check bytes and header information.
MPModem v1.60 Copyright (C) M. Jose Page 19
3.1.3 Modem/Port Options
-------------------------
The following is the screen which is displayed when you select the
"Modem/Port Options" off the master menu:
╔════════════════════════════╡Modem/Port Options╞════════════════════╗
║ ║
║ Enable FIFOs (only applies to 16550A series chips)........ Y ║
║ Number of bytes before interrupting. (1/4/8 or 14)........ 4 ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║Turn on UART buffer if there is one. Applies ONLY to 16550 & similar║
╟────────────────────────────────────────────────────────────────────╢
║Esc: Exit, : Move MPModem Configuration Copyri║
╚════════════════════════════════════════════════════════════════════╝
Enable FIFOs (only applies to 16550A series chips)
You can turn on or off the use by MPModem of the FIFO buffer
by setting this option. Generally you would want to use the
FIFO buffer (if you have a chip with it) but in the case
where you neither need nor want it, then just set this
option to N.
Soapbox:
The 16550 chip (and its consequent buffer) is a somewhat
over-rated chip. It seems to have become a necessity
because of badly designed systems and even worse written
software. I have thrashed the living daylights out of a
system with 16450 chips and experienced no problems. Yet
I can take the same software to another machine and
experience nothing but problems. A 16550 type chip will
not save you from badly written communications code. (I
hope mine doesn't fall into this category!)
MPModem v1.60 Copyright (C) M. Jose Page 20
Number of bytes before interrupting. (1/4/8 or 14)
This allows you to set the buffer used by the 16550 (and
compatible) chips. The optimum buffer size seems to be
around 4 bytes. Setting it to 1 makes it effectively act
like a normal unbuffered chip like the 16450 and its
predecessor, the 8250 series.
MPModem v1.60 Copyright (C) M. Jose Page 21
3.1.4 Communication Port Addresses
-----------------------------------
╔════════════════════════════╡Com. Port Addresses╞═══════════════════╗
║ ║
║ Port Base ║
║ Name Address IRQ ║
║ ║
║ COM1 3F8 4 ║
║ ║
║ COM2 2F8 3 ║
║ ║
║ COM3 3E8 4 ║
║ ║
║ COM4 2E8 3 ║
║ ║
║ COM5 3F8 4 ║
║ ║
║ COM6 3F8 4 ║
║ ║
║ COM7 3F8 4 ║
║ ║
║ COM8 3F8 4 ║
║Starting address of port 1. ║
╟────────────────────────────────────────────────────────────────────╢
║Esc: Exit, : Move MPModem Configuration Copyri║
╚════════════════════════════════════════════════════════════════════╝
Selecting this option allows you to change the base address
of the communications port you are running off (1 to 8 are
the only supported ports) as well as the Interrupt ReQuest
line number corresponding to that port.
The above values are the accepted defaults. DO NOT CHANGE
them unless you know what you are doing.
When setting port addresses, ensure you follow your
multi-port installation guide. There's nothing more
infuriating than seizing your system because of a wrong base
address or IRQ.
MPModem v1.60 Copyright (C) M. Jose Page 22
3.1.5 Miscellaneous Items
--------------------------
╔════════════════════════════╡Miscellaneous Items╞═══════════════════╗
║ ║
║ Date format DDMMYY ║
║ Date separator - ║
║ Time format 24 ║
║ Time separator : ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║Values DD (Day), MM (Month) and YY (Year) ║
╟────────────────────────────────────────────────────────────────────╢
║Esc: Exit, : Move, .: Change value MPModem Configuration Copyri║
╚════════════════════════════════════════════════════════════════════╝
This is the Miscellaneous menu. Currently this menu is selected
when you need to change the format of the time as displayed in both
the log file (MPMODEM.LOG) and the report file (MPMODEM.RPT).
Date format
There are three formats available. The default is DDMMYY
which is commonly referred to as the "European" format. It
is also used by Australia and New Zealand and so on.
The next format is MMDDYY which is used by countries such as
the USA.
The last format available is the international format of
YYMMDD.
DD represents the days, MM represents the month, and YY
represents the year.
To cycle through the various date formats, press the right
or left cursor keys.
MPModem v1.60 Copyright (C) M. Jose Page 23
Date separator
This can be one of the following symbols:
- : = . ~ / \ #
To cycle through the various separators, press the right or
left cursor keys.
Time format
The time format can either be shown in 24 hour (military)
time (which is the default) or as 12 hpur (am/pm) time.
When using 24 hour time, the display for 8pm and 25 minutes
would be displayed as 20:25:00 (assuming a time separator of
":").
When using 12 hour time, the display for the same time would
be 8:25 pm, again assuming a time separator of ":".
Again, to toggle through the two alternate time displays,
press the left or right arrow/cursor keys.
Time separator
See "Date separator", above.
MPModem v1.60 Copyright (C) M. Jose Page 24
3.1.6 Screen & Colours Setup
-----------------------------
This screen allows you to change the colours of the various screens
used by MPmodem and its associated programs.
If you don't have a colour monitor then this option is superfluous
to your needs.
╔══════════════════════════╡Screen & Colours Setup╞══════════════════╗
║ ║
║ ║
║ Screen Background colour ║
║ Screen Borders ║
║ Field Names ║
║ Text & Data Info. ║
║ Status line ║
║ Message colour ║
║ Warning colour ║
║ Menu Bar colour ║
║ Menu text colour ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║ ║
║The colour of the background of the screen. ║
╟────────────────────────────────────────────────────────────────────╢
║Esc: Exit, : Move MPModem Configuration Copyri║
╚════════════════════════════════════════════════════════════════════╝
MPModem v1.60 Copyright (C) M. Jose Page 25
3.1.6 Save Configuration
-------------------------
Moving to this option and pressing [Enter] will cause the
current settings to be saved to a file called "MPMODEM.CFG".
Ensure that before you quit (unless you do not want to save
your changes) that you select this option.
MPModem v1.60 Copyright (C) M. Jose Page 26
4.0 Running MPModem from DOS
-----------------------------
MPModem runs by specifying switches on the command line. Some of
the command line switches are optional but a few are mandatory such
as the Port and the transfer type. Below are detailed a list of the
switches/options you may use with MPModem:
Switch/
Option Description
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-@ This causes Ymodem or Zmodem to obtain the list of
filenames to send to the remote from a file. To
use this you must follow this switch with the
filename to use. E.g -@ input.fil
Note that there must be a space after the "-@" and
then the filename. For more details of the make up
of the input file to read from, see "Input File".
Note also that any filename given on the command
line will be ignored and precedence given to the
"-@" switch.
This switch is optional.
-a When using Zmodem this forces the transfers to be
-A made in Ascii (raw text) mode. Thus transfers
from Unix or Macintosh sites will result in the LF
converted to a CR/LF combination compatible with
DOS.
Using this switch with a Binary file will result
in unmentionable things happening to the file!
This switch is optional.
-b This sets the baud rate. Immediately following the
-B "-b" must be the baud rate. Any baud rate is
supported, but the general ones used are: 300,
600, 1200, 4800, 9600, 19200, 38400, 57600,
115200.
For example,
-b9600
will specify that the transfer is to take place at
9600 baud.
I recommend you DO NOT use this option, but
instead configure MPModem (via MpConfig) to use
the existing baud rates. The only time this option
is necessary is when you have a direct
(null-modem) connection.
This switch is optional.
MPModem v1.60 Copyright (C) M. Jose Page 27
-c Make Zmodem run in compression mode. As long as
-C the other end of the transmission can also send
using this type of compression, then Zmodem will
attempt to compress ALL packets/frames sent. It
will, however, only send a compressed packet when
that packet is smaller than the uncompressed
packet.
This switch is optional.
-f Run Zmodem in fast mode. This greatly depends on
-F the remote's ability to run Zmodem in non-standard
mode. This is an adapted version of PC²'s turbo
mode. The main difference is my version DOES NOT
rely on variable headers which seem to be
copyright to Chuck Forsberg.
This switch is optional.
-l Run Zmodem with large blocks. The normal block
-L size of Zmodem is 1024 down to around 64 bytes.
When this is selected (and the remote can do
likewise), then the blocksize will range from 4096
to around 64 bytes.
This switch is optional.
-n This switch allows you to override normal Zmodem
-N practice of defaulting to CRC-32 when protecting
the packet and transmit using CRC-16. The overhead
is reduced by 2 bytes per packet and on quite safe
and noise free lines will offer you protection
with the benefit of a saving in the overall
transfer time.
This switch is optional.
-p Defines the port number. MPModem can operate from
-P ports 1 to 8. You must specify the port number (1
to 8) directly after the switch,
eg. -p1 will make MPModem run from Port 1 of your
machine.
This switch MAY be optional. If you have used
MpConfig to set the port number, then this switch
will be overridden. If you have not set the port
number in MpConfig, then you MUST specify it on
the command line.
MPModem v1.60 Copyright (C) M. Jose Page 28
-r Causes MPModem to go into receive mode. You may
-R specify 5 individual protocols to use:
-rx Receive Xmodem (128 byte packets)
-ry Receive Ymodem
-rz Receive Zmodem
-rg Receive Ymodem-G
-rk Receive Xmodem (1024 byte packets)
You MUST specify at least one of these commands on
any command line if you are receiving files.
-s Causes MPModem to go into send mode. You may
-S specify 5 individual protocols to use:
-rx Send Xmodem (128 byte packets)
-ry Send Ymodem
-rz Send Zmodem
-rg Send Ymodem-G
-rk Send Xmodem (1024 byte packets)
You MUST specify at least one of these commands on
any command line if you are sending files.
-t This switch is used mainly used by BBS operators.
-T It enables sysops to see what time is left for the
user while running MPModem. It also enables users
to keep track of the total transfer time over more
than one transfer.
This switch is optional.
-u Use this switch ONLY when you are running MPModem
-U from a BBS. Follow this switch with whatever
option your BBS has for putting the Usernumber on
the command line of an external protocol. For
example, RemoteAccess allows you to put a user's
number on the command line by entering the
following:
-U*R
Thus MPModem can use this information to report on
any suspicious activity by the user.
This switch is optional.
MPModem v1.60 Copyright (C) M. Jose Page 29
-v This switch enables users to specify respectively
-V the user's name or the system they are attached
to. If you want to use the entire name (first name
and full name) then you must join the two names
with an underscore (_).
For example, running RemoteAccess you may specify
it as:
-v*F_*L
which will join the user's first name with his
last name by an underscore.
This switch is optional.
-w Sound a "warble" when the program has finished
-W its transfers.
This switch is optional and dependant on the
above.
-x Put Zmodem into command mode. This switch can be
-X invoked on its own or with the further parameter
of "W" or "w" which will cause the receiver to
quit and then execute the command. If you don't
specify "W" or "w" then the receiver/sender will
execute the command just like a shell. When the
command is finished, control will return to the
receiver/sender.
To enable this command you must have set the
option of "Allow remote to execute
programs/commands?" in the configuration program
under the option "File Transfer Options" to Y. If
you have NOT set this and the remote sender tries
to send you a command then it will be rejected and
a message reported (for security reasons mainly).
For more information, see the section called
"Executing commands with Zmodem".
NOTE: This command only works when you specify the
transfer type as Zmodem (-rz or -sz).
-y Put Zmodem into resume mode by force. If you have
-Y not specified that you ALWAYS want Zmodem to try to
resume a transfer (this is done via the
configuration program) then specifying this switch
will allow you to resume files for the duration of
this session only. This switch is preferable to
the option in the configuration file because the
configuration file option will ALWAYS force Zmodem
to resume, even when you may not want it to.
This switch is optional.
MPModem v1.60 Copyright (C) M. Jose Page 30
4.0.1 BBS Users
----------------
If you are a BBS operator, then the screen will differ from what
"Normal" users will see. At the very bottom of the screen will
appear a rectangle which will display the following information:
User BBS User
---------------------------------------------------------------
BBS Name connected to. Current online user.
Baud rate (Connect rate) Baud rate (Connect rate)
Time online so far Time remaining
User
~~~~
If you can pass to the program from your calling communications
program like Telemate, Procomm or Telix the following
information, then it will appear on the screen:
-vBBSName
-tTimeOnline
"BBSName" is the name of the BBS you are currently calling.
"TimeOnline" is the current amount of time you have been online.
This information is ideal for allowing you to keep accurate track
of where you are logged in and how much time you have spent on
that board.
Telix is able to pass (via a script - an example is enclosed) the
name of the system you are connected to but not the time. It is
therefore necessary to pass a value of 0, as in "-t0".
The time value MUST be given in minutes, not seconds or hours.
Other communication program may be able to do this and if so
good, but Telix is my program of choice so I have not had time to
experiment. If you write a script, then email it to me. DO NOT
INCLUDE IT IN THE BUNDLE OF SOFTWARE CONTAINING MY PROGRAMS!
Telemate (v3.10) allows you to create scripts but does not allow
you to link these scripts to the receive/send menu. Consequently
you can only use batch files to execute additional protocols.
You can, however, directly execute the scripts (.SCR) included
with this package by typing ALT-S and selecting the relevant
script.
MPModem v1.60 Copyright (C) M. Jose Page 31
BBS User
~~~~~~~~
To aid in the better monitoring of who is using your Board, I
have included the additional status line. This line will display
the current user online, the baud rate he connected at and the
time remaining (in minutes).
This should greatly assist BBS operators.
MPModem v1.60 Copyright (C) M. Jose Page 32
5.0 File Formats
-----------------
5.0.1 Input File
-----------------
The format of the input file is quite simple. It must be in ASCII
and each line must be less than 80 characters in length.
A line is just plain text with a CR/LF combination at the end.
An example of what an input file would look like is detailed below:
c:\programs\hold\pibterm3.lzh
mpmodem.exe
c:\games\canasta.lzh
There is no limit to how many files can appear in the file, it
really only depends on how long you have to send all the files to
the remote end.
5.0.2 Log file format
----------------------
The log file is made up of pure ASCII (decimal 32 to 127 inclusive)
and thus can be read by any program or editor. The following is an
example of the MPMODEM.LOG file:
21-12-91 00:36:38 Zmodem Download
21-12-91 00:36:38 Remote filename: Planets Movie.cpt
21-12-91 00:54:59 Received: Planets_.cpt
21-12-91 00:54:59 Bytes: 207534
21-12-91 00:54:59 CPS: 1780
21-12-91 01:01:20 Zmodem Upload
21-12-91 01:03:24 Transmitted: QUICKTME.CPT
21-12-91 01:03:24 Bytes: 765010
21-12-91 01:03:24 CPS: 1970
Each line of the log file begins with the date in DD-MM-YY format
(there are no spaces before the date). Next follows two spaces then
the time in the format of HH:MM:SS in 24 hour notation so that
22:10:12 is 10:10:12pm. A further two spaces follow and then
appears the type of download or upload, either "Transmitted:" or
"Received:" , the number of bytes received and the CPS rate.
MPModem v1.60 Copyright (C) M. Jose Page 33
5.0.3 Report file format
-------------------------
The report file is a pure ASCII file similar in appearance to the
standard MPModem log file called "MPMODEM.LOG".
The following is an example of what part of this file may look
like:
21-12-91 00:36:38 25 has received all of file MPMODEM.EXE
21-12-91 00:36:38 25 has asked me to execute commands
The "25" above refers to the user's number, and will only be
displayed if you specify "-u" or "-U" on the command line followed
by the BBS's code for a user number (see "-u" switch).
The report file is used to report on strange occurrences during a
file transfer. Some users have been known to abort the receipt of
files just after the last bytes have been received and just before
the End Of File packet has been sent. This then makes the BBS think
that the file was not sent and thus this user's download amount is
not adjusted. So, if a Sysop browses through this file he will
immediately ascertain which users should be barred from using the
file system or whatever.
MPModem v1.60 Copyright (C) M. Jose Page 34
6.0 Future Enhancements
------------------------
MPModem is by no means complete and will be continually updated to
ensure users are able to use the most modern aspects of the
protocols that make up the MPModem product.
Don't expect the updates to be thick and fast - as the old adage
goes - you get what you pay for. As you paid nothing, expect no
more...
If you have general problems with the program I would be more than
pleased to know about them.
MPModem v1.60 Copyright (C) M. Jose Page 35
7.0 Messages
-------------
7.0.1 System Messages
----------------------
Detailed below are all the major system messages that occur when
using the MPModem product. Some are general messages or notices but
most are error messages.
Bad data CRC.
While receiving data in either CRC 16 or 32 bit mode, MPModem
the final CRC checking values did not agree with those sent by
the sender. This can indicate two things, a very noisy line
which is continually subjected to noise bursts or a badly
designed sending program which may be experiencing transmitter
overruns.
If the problem always persists on the same connection, it may
point to a software error in the sender's software otherwise
it may just be a bad exchange or telephone line. Perhaps you
should hang up and call back - after all Zmodem can resume
transfers.
Bad data subpacket.
You are experiencing major problems where data is becoming
grabled by either a lousy telecommunications line. Try hanging
up and calling again. Maybe even cleans the contacts on the
telephone socket and plug - it sometimes help. (Use a 600
grade sandpaper or better still Emery paper).
Bad position.
The current packet (just received) is not the next packet we
wanted to receive so we will tell the remote and he SHOULD
send us the correct packet. Too many of these errors will
result in the "Too much garbage. I give up!" message
appearing. See that error message for more details.
Break detected - receiver interrupted.
The communication routine has detected a break signal sent by
the remote (the sender) to you (the receiver). This will cause
the protocol to lose some characters. The communication
routine will wait for the next byte to arrive correctly.
MPModem v1.60 Copyright (C) M. Jose Page 36
Cannot resume transfer - entire file already received.
Zmodem has been instructed to try to resume a transfer (either
by the -Y switch on the command line or as defined in the
Configuration program (See section 3.1.1, "File Transfer
Options Screen") but cannot do so because the file to be sent
is the same size as the one we already have. In this instance,
we have had to reject the file.
If the file is not the same, then turn off resume (either do
not specify "-y" on the command line or set the appropriate
question in section 3.1.1 to 'N'). This will make MPModem
create a unqiue filename.
Carrier Lost.
If you have set MPModem to watch for carrier dropouts then
when such an event occurs, MPModem will report this message.
Note that if you are direct connecting it would be wise to not
monitor the carrier signal and thus avoid a possible problem.
Command file missing. Read the manual.
You have invoked MPModem with the "-x" switch (you may have
also invoked it as "-xw") and MPModem expects to find the
command you wish the receiver to execute in the file called
"MPMODEM.CMD". This file should be in the same directory as
your MPMODEM.EXE, and MPMODEM.CFG file. If it isn't there then
MPModem will not find it. Simply relocate it to there and
re-run MPModem.
Please refer to section 10, "Executing commands with Zmodem"
for full details of how to go about sending commands.
Command successfully sent to receiver.
A command sequence located in the "MPMODEM.CMD" file has been
loaded and sent to the receiver successfully. If the receiver
can handle the command, it should execute it and finish.
Data overrun. System load too high.
The system has been unable to act quick enough to take an
assembled byte from the UART (8250,16450 or 16550 type chips)
prior to the next byte having been received and assembled.
This can be caused by a broken (incorrectly coded) receive
routine but is more likely the result of too high a system
load - especially when you are multi-tasking. After all, DOS
is not a multi-tasker and the manipulation that has to go on
to simulate this is a credit to the writers of this code.
MPModem v1.60 Copyright (C) M. Jose Page 37
Data subpacket too long.
Too much data has been received for this packet. Again, this
points to a noisy line or faulty contacts. Perhaps someone
just picked up the other extension and interfered with your
call. Yell at them if that's the case!
Data TIMEOUT.
While receiving data from the sender, MPModem got tired of
waiting. This can point to a slow remote system or a lazy
network. Firstly investigate the possibility that the remote
is slow before pointing your finger at the remote's network;
It's harder to diagnose!
Error reading the configuration file!.
The configuration file is either corrupt, old or for a version
of MpModem other than the one it was intended for.
You are best to delete the configuration file called
MPModem.Cfg and run MPConfig.Exe to create a new configuration
file.
Error: Carrier Lost.
Zmodem has encountered a loss of carrier. This message will
only appear when you specify the "-c" switch on the command
line.
Error: Garbage in header.
See "Garbage count exceeded (Header)".
Error: Received a garbled packet.
Zmodem has received a data packet (part of the actual file
transfer) that is garbage. It will discard this packet as
corrupt.
Error: Receiving ZCOMPL.
Zmodem has continually received ZCOMPL (Zmodem has finished
the file transfer) out of sequence. It may indicate that the
remote is not ready for the files.
MPModem v1.60 Copyright (C) M. Jose Page 38
Error: Remote Cancelled!
Zmodem has received a cancel sequence by the remote and is now
also ending the file transfer.
Error: Strange characters received!
Zmodem has encountered some irrecoverable error or errors when
receiving a file. The transfer is obviously becoming far too
"mutilated" by the telephone or network system.
Error: Timeout.
A timeout has been received. Please see "Timeout" for more
details.
Error: Too many CRC errors!
While Zmodem is receiving the file it has encountered too many
CRC errors to be considered safe to continue the file
transfer. If this continues to occur then email me and I may
put a switch in so that you can specify the number of times it
will allow for CRC errors during the file transfer. Currently
it is about 15.
Error: Too much garbage. I give up!
Zmodem has given up trying to receive the file because it
keeps receiving data packets with a different file position to
that of the current file position. This may indicate that the
sender is no longer receiving information.
Error: Trying for ZCMD.
Zmodem has given up trying to respond to the request for some
action (command) to be taken by the remote program. This
version of Zmodem can execute a command (such as another
program) and then return back to Zmodem or it can execute a
program that replaces Zmodem in memory. While trying to do one
of these things, no response was received by the remote
program.
Error: Trying for ZFILE.
Zmodem has given up trying to receive the file header. End of
story and end of transfer. It is possible the remote end has
dropped out or has failed to load their Zmodem program.
MPModem v1.60 Copyright (C) M. Jose Page 39
Error: Trying for ZSINIT.
Zmodem has given up trying to send an initialisation sequence
to the remote program. It is possible the remote end has
dropped out or has failed to load their Zmodem program.
Existing file cannot be overwritten.
This indicates that the sending program is trying to send a
file that is on your system as either Read-Only, Hidden or
System. This could indicate that the remote is trying to
upload a copy of the the system files or other types of
protected file. If it is one of the system files, then maybe
it was an attempt at sabotage!?!
At any rate, the attempt has failed and that file will be
skipped.
FIFO buffer error. One or more bytes garbled.
You have the FIFO buffer enabled and since the last read of
the buffer 1 or more of the bytes in the buffer has been
received in error. For more information, see the notes
relating to the following error messages:
Break detected - receiver interrupted.
Framing error. Stop bit wrong.
Parity error. Wrong bit sequence.
Data overrun. System load too high.
File positioning error.
While trying to move the disk pointer to another location
within the file, an error was encountered and consequently the
program could not reposition within a file. Generally this is
a SERIOUS error as it indicates a problem in either the FAT
tables or a problem with the actual media (hard or floppy
disk).
File transfer failed.
Because of some reason the file transfer has failed. If you
are concerned that file transfers are continually failing then
read the documentation again and perhaps watch the transfer to
see just what type of error messages appear during the file
transfer.
MPModem v1.60 Copyright (C) M. Jose Page 40
Framing error. Stop bit wrong.
For some reason the stop bit count was either wrong or
missing. This can be caused by many things but one thing I am
aware of is when running in multi-tasking, you inadvertantly
run another program which uses the SAME communications port.
If you get this error consistently, then you may wish to
contact your modem supplier.
Garbage count exceeded (Header).
While trying to receive a header packet, Zmodem has
encountered too many errors. These errors are possibly due to
a noisy line or indeed could be caused by a faulty modem or
modem cable. Check that no earthing is occurring with the
cable.
Got bad Zmodem escape sequence.
Zmodem "escapes" certain codes so that they aren't confused
with other possible codes like XON/XOFF software flow control
bytes. If Zmodem encounters a bad "escape sequence" that
doesn't make sense to it, it will produce this error. Again
this points more to a noisy or ineffective line than anything
else.
Interruption detected! Trouble?
Zmodem has received an interruption (some bytes from the
remote - possibly a Cancel or Reposition command) and will
attempt to rectify the problem.
This problem can be caused by improperly designed transmitter
hardware or software and can point to transmitter overruns. If
this continually occurs then contact me via email and I will
endeavour to help you. Please site the type of chip you have
(8250, 16450 or 16550) and any details you may have.
Invalid block number. (?? tries)
Xmodem, Xmodem-1k, Ymodem, Ymodem-G has continually tried to
receive the next block number but each time it is invalid. The
"??" is replaced by the number of attempts the program has
made to try to obtain the correct block.
MPModem v1.60 Copyright (C) M. Jose Page 41
Invalid chksum/crc. (?? tries)
Xmodem, Xmodem-1k, Ymodem, Ymodem-G has received an invalid
checksum or CRC value. The "??" is replaced by the number of
times we have received this invalid checksum or CRC value.
If you are running Xmodem with checksum, you should consider
changing/forcing the remote to run under CRC because checksum
checking of a packet WILL NOT catch all errors and thus you
could end up receiving a file that is corrupted!
Invalid Binary Header CRC.
This means that a corruption has occurred when receiving a
header record in Zmodem. Generally it indicates a poor line.
If it persists it could point to bad software design by the
remote sending program.
Invalid header received. (?? tries)
Xmodem, Xmodem-1k, Ymodem, Ymodem-G has continually tried to
receive a header from the remote sender. The "??" is
substituted with the number of tries so far.
Hang up and try again if it persists.
Invalid Hex Header CRC
The hex header (used when initiating file transfers) has
encountered a CRC error in the header. This is due to line
noise corrupting the individual bits in a file transfer. If
you encounter too many of these errors you would be wise to
hang up or abort the transfer and start again.
Invalid response (??)
When the sender (Xmodem, Xmodem-1k and Ymodem) have finished
sending a block of information, they expect to receive a
certain character from the receiver telling them what they
should do next. When this message is returned it indicates
that the program has recieved an invalid character. When the
message is displayed, the "??" is replaced with the
hexadecimal value of the character received.
It means that some spurious character has been received. If it
continues, the program will eventually abort.
Local abort.
You have pressed the <Ctrl>-<Break> (System break) keys.
MPModem v1.60 Copyright (C) M. Jose Page 42
MPMODEM.CFG is an old version (??.??). The version should be ??.??.
The version of MPModem.cfg is not the right version required
by this release of MPModem. You have two courses of action.
You can run the "cfg-conv" program to update the configuration
file. If this fails to work (quite likely if it is a very old
configuration file), then you will havbe to delete it, run
MPConfig.Exe, re-set your various options and save the file.
You will then be ready to run MPModem.
No files to send!
When you specify a filename, (can be wildcards like fred*.*),
and the program fails to find any files matching this
description, it will announce that it has "no files to send"
and will stop the transfer at this point.
Not enough memory to create command buffers. (????).
There is simply not enough memory left to create the buffers
which have a total length equal to the figure in brackets. (I
have placed question marks in the above message).
Try freeing up some memory some how. You should only need
about 2k to be safe.
Parity error. Wrong bit sequence.
The wrong parity bit has been received or in other words it is
inconsistent with the default setting of N or No parity.
This could indicate a problem in the other ends
software/hardware sending in the wrong mode or it could mean
your modem is playing up.
Receiver has entered command mode.
This is the last entry made in the log before the shell is
executed. The shell (called SH.EXE) will execute the commands
sent by the remote (sender) Zmodem.
Remote cancelled!
The remote sender or receiver has aborted or escaped out of
the protocol and has told us to stop sending or receiving. Any
file currently being transferred is close and the program
ends.
MPModem v1.60 Copyright (C) M. Jose Page 43
Remote filename: ??????????
(This is NOT an ERROR message but rather a WARNING/NOTICE message).
When you use the "-m" switch, MPModem will display the file it
received from the remote prior to amending it so that it would
fit within the parameters of a DOS file. For example, you may
be receiving a file from a Macintosh system called:
Some Macpaint Pics.cpt
MPModem will convert this filename and display it as
"Some_Mac.cpt". MPModem will then display (as a notice):
"Remote filename: Some Macpaint Pics.cpt"
Remote refused file!
Zmodem tried to send a file to the remote but for some reason
the file was rejected. Zmodem will endeavour to send the next
file (if there is one) or else it will finish the transfer at
this point.
The most probable reason is that the remote already has the
file or the file you are trying to send exists on the remote
as a hidden, system or read-only file or even as a directory.
Repositioning.
This tells you that the protocol is undergoing an error
recovery by stepping backwards into the file to replace data,
already sent and found corrupt, with the correct data.
In X/Ymodem this involves going backwards in the file by the
amount of the current blocksize (128 or 1024 bytes) and with
Zmodem it can mean going back to anywhere in the file.
The position of where the program is re-starting the transfer
from is displayed to the left of this message.
Request to escape control characters rejected.
This can occur in both send and receive mode. What it means is
that you have tried to start a Zmodem session with both Fast
and Escape Control Character mode enabled (or the
sender/receiver has requested it when you want a Fast
transmission). Basically the two cannot combine. Fast mode
skips all escape encoding (other than Zmodem's special
character) whereas Escape Control Characters wants all control
characters escaped. See the dilemma?
MPModem v1.60 Copyright (C) M. Jose Page 44
Requested COM?. This program only supports COM1: to COM8:.
If you got this error message then you obviously specified an
incorrect port number; or did you?
If you used the command line switch "-p" followed immediately
(that is without a space after the "-p" such as "-p1" for port
1), then you must reenter the command line with the correct
port number.
You may, however, have not specified a port number on the
command line. This is fine if you have "hard-coded" the port
number you use in the configuration file, but if that also is
blank then this message will be generated. Either specify the
port number on the command line via the "-P" switch or set it
in the configuration program.
Sender has entered command mode.
At this stage the sender is trying to get the receiver to act
upon the commands it is now sending. Depending on whether the
receiver allows commands, the command sequence will either
complete successfully or be aborted by the receiver.
Sender's commands rejected.
The Sending side of Zmodem has tried to get us (the receiver)
to execute commands. Because you have not allowed this via the
configuration program MPCONFIG.EXE, the command is ignored and
the transfer completed.
Sending data header.
This is not an error message but rather it indicates that we
are about to start sending the file.
Sending EOF.
Zmodem is trying to tell the receiver that it has finished
sending the file and that it will shortly be sending another
file (if there is one more to be sent).
Sending file.
Zmodem is in the process of sending a file.
Sending ZRQINIT.
This indicates that Zmodem sending routine is trying to get
the transfer started by sending the prompt to the receiver to
make it start up.
MPModem v1.60 Copyright (C) M. Jose Page 45
Serialisation error returned 0X??.
This means that a combination of serial errors was received
possibly indicating a dead or near-dead UART chip. To first
eliminate a software problem, please record the hexadecimal
number (which will be in place of the "??" above) and advise me
by email (if possible).
Setting start position
This indicates what position within the file the sender will
be starting the file transfer from. Generally it is 0, meaning
the start of the file but when the receiver wants us to resume
a file transfer it will indicate some other position within
the file.
This is not an error message.
TIMED OUT!!!!!!!!!
An Xmodem, Xmodem-1k, Ymodem or Ymodem-G file transfer has
aborted because it has waited too long to either send or
receive a file. This can be caused by either end becoming
stuck because it missed the XON character after the XOFF
character had been received.
If this occurs often enough, please contact me at my E-mail
address.
Timed out waiting for entire buffer to clear.
Zmodem has timed out while trying to clear the current
transmit buffer. This points to a serious error in your system
setup or the actual 8250, 16450 or 16550 chip. Try the
transfer using a different protocol and if the situation
persists then have the chip replaced.
If you believe it is this program's fault then please send me
a message via E-mail.
Timeout.
Either the receiver or transmitter routines have timed out
while waiting to receive or send data. This generally means
that the other end has been delayed (maybe it is a slower
machine than yours) or that your machine is taking too long to
handle the output of data.
This is not a serious problem but can indicate a loss of
carrier if the "-c" switch was not used. Maybe you should try
the "-t" switch which will create a time out value more in
line with the Baud rate than the standard time out value.
MPModem v1.60 Copyright (C) M. Jose Page 46
Timeout (?? tries)
Xmodem, Xmodem-1k, Ymodem, Ymodem-G has continually timed out.
The "??" is substituted with the number of tries so far.
It is quite possible that you have lost connection with the
other end. If you have not specified the "-c" switch on the
command line then it may be wise to do so in the future.
Too many repositions!
Zmodem has got sick of repositioning to the same point in the
file. This generally indicates there is a problem with the
receiver receiving our packets and may indicate an extremely
noisy line or the fact that Zmodem has somehow got entirely
out of sync.
Unable to allocate enough memory for I/O Buffer! (??)
MPModem has failed to obtain enough memory from the free
memory pool and thus cannot run in the current environment.
If you are multi-tasking then increase the allocation of
memory for MPModem. If you are not then removing some of the
TSRs will help alleviate the problem. If there is still not
enough room then you may have to reduce the size of any disk
cacheing or BUFFERS.
Unable to allocate memory (1k)
The sending routine of Zmodem could not obtain enough memory
from the free memory pool. All it needs is a lousy 1024 bytes
of memory so please adjust your memory requirements
accordingly.
Unable to create a unique filename.
When a file is received by Ymodem, Ymodem-G or Zmodem and you
do not want files to be resumed (Zmodem only), and the file
name received is the same as an existing one, then MPModem
will endeavour to create a unique filename. Generally, it will
replace the last character in the file extension (if it has
one) with the letter 1, or if that fails 2 or if that fails 3
and so on.
For example, suppose we already have a file called "test.txt"
and suddenly Ymodem says it has another file called
"test.txt". MPModem will now check to see if there is a file
called "test.tx1". If not it will create such a file. If there
is then it will create a file called "test.tx2" and so on
until it gets to "text.999" before it aborts! This situation
should never happen.
MPModem v1.60 Copyright (C) M. Jose Page 47
Unable to open file.
Well just as it says, MPModem was unable to open the file. If
you are transmitting something, then this can indicate that
the disk is bad, the file is bad or it is just plain missing.
Fix it if possible. If it's missing, then perhaps you typed
the name wrong?
If you are receiving a file then it means you either have a
bad disk or you are receiving a file from a remote site (like
a Macintosh (tm) System) and have not specified the "-m"
switch. Do so now and start again.
Verifying CRC of file.
In Zmodem, it is possible for the remote system to request a
CRC of the file you have just received. It is a means of
trying to ensure correct reception of data not just over the
telecommunications line but also in the writing of the file to
disk. (NOT IMPLEMENTED)
Waiting for receiver.
Zmodem sending routine is now waiting for the sender to get
back in synchronization with us. This is a normal occurrence
at the end of each file.
Waiting to send file(s).
The Zmodem send routine is now waiting (patiently I might add)
for the receiver to give it instructions on various important
aspects of the file transfer. Without these instructions,
Zmodem cannot proceed.
MPModem v1.60 Copyright (C) M. Jose Page 48
7.0.2 Report File Messages
---------------------------
Detailed below are the various report file (MPMODEM.RPT) messages
that appear when you run this program from a BBS.
<Usernumber> has received all of file <filename>
This tells the sysop that <Usernumber> (A user's system
number) has received all of <filename>. Because MPModem did
not have time to close off and do all necessary file handling
the user has essentially got the file for nothing. The Sysop
may want to note the users that continually have this
"problem" because they may be experiencing real problems or
they may have a "re-coded" version of Zmodem allowing them to
grab files for "free".
Unable to create unique filename. File: <filename>
MPModem tried to create a unique filename for <filename> but
failed. This either indicates disk/storage media problems or
you may already have upto 999 connotations of the filename.
The latter is highly unlikely as you would have to have:
(assuming the filename is "FRED.CPT")
FRED.CP1
FRED.CP2
.
.
.
FRED.999
This means that you would have to have 1000 files (as detailed
above) and this would be unlikely. If it is neither of these
then contact the author (after you have tried again to receive
the file).
Existing file cannot be overwritten. File <filename>
The <filename> being received already exists on your system
and is either Read-Only, Hidden, System or a Volume Label
Name. Either way, this is not a serious message as MPModem
will simply reject such files.
MPModem v1.60 Copyright (C) M. Jose Page 49
File positioning error.
This can happen when both receiving and sending. Generally
this indicates (when sending) that the receiver has asked us
to reposition past the End-Of-File. The same can go for
receiving.
Generally, it is wise to assume that it could be a disk
problem so run CHKDSK or its equivalent and perhaps some type
of disk diagnosis tool to assure yourself that the disk media
is not at fault.
MPModem v1.60 Copyright (C) M. Jose Page 50
8.0 Exit Codes
---------------
The following exit codes are generated when MPModem finishes the
session:
Code Description
---------------------------------------------------------------------
0 Normal exit. (Could be you or the remote have
cancelled the transmission).
1 Carrier has been lost.
2 Invalid baud rate. Out of the supported range of
0 to 115200.
3 Invalid communications port specified on the
command line. Supported values are 1 to 8.
4 Unable to open the Configuration files called
MPModem.Cfg.
Generally a message will be shown on your screen
and if MPModem can write to the report file, it
will also write the reason in there.
5 MPModem was unable to read the configuration.
Possibly the file is either missing or an old
version. If it is the latter, then run
"cfg-conv.exe" try to update it. Check the contents
of the MPMODEM.RPT file - it may contain the
answer.
6 MPModem could not read or parse the options
contained in the MPMODEM.CTL file. This file should
meet the specifications of OPUS.CTL and is used
when running this program from a BBS.
7 Unknown transfer option. Type MPModem on its own
to see the various transfer options or refer to the
relevant section of this manual pertaining to the
switches "-r" and "-s".
8 General invocation error. Either you have not
specified the right switches on the command line or
are missing some of the REQUIRED switches.
9 MPModem has been called with the "-@" switch which
causes it to look for a file named "MPMODEM.FIL" in
the directory where MPModem resides. (MPModem's
directory can be changed with the environment
variable MPMODEM). Thus the file cannot be found or
opened.
10 Reserved.
MPModem v1.60 Copyright (C) M. Jose Page 51
11 You haven't supplied a path/filename for the
specified file transfer. Generally this means you
have tried to run Xmodem without specifying a
filename. Remember Xmodem CANNOT pass the filename
to the receiver like Y or Zmodem can.
12 MPModem could not find the command file,
MPMODEM.CMD (which should be where the MPMODEM.CFG
file is) or it could not allocate enough memory to
transfer a command using Zmodem. See section 10 on
how to send commands.
99 My program has been tampered with. Either you are
breaking the law or a virus has attached itself to
your copy of MPModem. If it is the former, may you
die a lingering death! If it is the latter, get a
virus kit QUICKLY.
MPModem v1.60 Copyright (C) M. Jose Page 52
9.0 Running MPModem from a Bulletin Board
-----------------------------------------
As of version 1.60 of MPModem, it no longer directly supports
bulletin boards (in the past this program supported RemoteAccess -
a bulletin board based originally (I think) on QBBS).
MPModem does still, HOWEVER, support bulletin boards running it. It
does this by using the very common file format of OPUS. The format
is (was) based on the standard OPUS.CTL file for filedoors.
So long as your bulletin board can invoke this program (which uses
little memory) and build a .CTL file called MPMODEM.CTL in the
format it requires, then this program will run off your bulletin
board.
The format required is as follows:
Line 1: Port Number (an integer from 1 to 8).
Line 2: Baud rate.
Line 3: NOT USED.
Line 4: Time remaining (in minutes).
Line 5: Either the download directory or the start of the upload
list.
.
.
.
Line xx: End of upload list.
Some explanations:
The port number can be made redundant by specifying it in the
configuration file. See section 3.1.2 "General Setup Options
Screen" for more details or just run MPConfig, go to the second
menu option and scan down the page for the option to select the
port number and make it the default.
The baud rate can also be made redundant by specifing in the
configuration file that you want MPModem to use the values
already set - rather than initialising them. See section 3.1.1
"File Transfer Options Screen". Generally it is advisable to set
this to 'Y' because some bulletin boards only pass the carrier
rate (rather than the connect rate) to the control file. If
MPModem uses this rate your transfers will be garbled and won't
even start.
NOTE: Both port and baud rate ARE NOT necessary if you
select the option in the "File Transfer Options
Screen" (see section 3.1.1) called "Use current Comm.
port settings for Baud rate?" and set it to Y. This
means baud and port settings (except FIFO buffer) will
be untouched by MPModem.
It is recommended you do the above (even if you supply
the port and baud rate).
MPModem v1.60 Copyright (C) M. Jose Page 53
Line 5 can be one of two things. If the MPModem program was
invoked by someone wanting to send files to your system, then
this line will contain the download directory where those files
are received into. If the user wants your system to send files,
then line 5 (and onwards) will contains the names and paths of
the files MPModem will send to the user.
If all these criteria can be met, you should have a seamless
integration of MPModem into your bulletin board system.
MPModem v1.60 Copyright (C) M. Jose Page 54
9.0.1 Reading the log file to obtain transfer details
-----------------------------------------------------
Most bulletin board program designers seem to have enough
forethought to have allowed for external protocol and the proper
handling of them. In this case, they would have also allowed for
options, when setting up an external protocol, to enable the
extraction of the transmitted or received file and the filename.
RemoteAccess is one of those programs.
In order for your system to know which files were transferred and
what size they were (especially for incoming files), it has to have
some way of scanning through the log file (MPModem.Log) and
extracting the relevant details.
What it needs to be able to do is scan for the following (on each
line of the log file):
At offset 20 (for compilers which start at 0) and 21 (for
compilers which start at 1) is the following important
information.
"Transmitted:" - One space after this is the full path of the
file SENT (downloaded from the BBS).
"Received:" - One space after this is the name of the file
RECEIVED (uploaded to the BBS).
Do not use the "Remote filename:" whih appears
in the log file. This could be a strange
filename before conversion to DOS. For example,
it could be a Macintosh file called "Red Rover
Over and Out", which will become a "Received:"
filename of "Red_Rove". "Bytes:" - One space
after this is the amount of bytes sent or
received.
If for some reason your system does not allow for this, then search
around for a filedoor that will allow you to do this. If you still
have no luck then let me know, perhaps I could write a quick
filedoor to correct the problem.
ANY requests for MPModem to write DSZ style log files will be
rejected outright. As the log is part of the author's (of DSZ)
copyright, it too falls within these bounds unless specifically
denounced. So there!
MPModem v1.60 Copyright (C) M. Jose Page 55
10.0 Executing commands with Zmodem
------------------------------------
Make sure you have read the information regarding the relevant
switch "-x{w}" prior to reading this section.
MPModem allows for the sending of command sequences to the remote
end which will then (if allowed) execute those commands or even
exit to a shell (which is called SH.EXE).
Commands can ONLY be sent by the sender and can only be executed by
the receiver. All commands are to be in the MPModem path (set by
the environment variable MPMODEM or else it defaults to the path
where MPModem was executed from) in a file called MPMODEM.CMD.
Only one line of commands are allowed. Any more than one line is
ignored. For unix systems this isn't a problem as you can separate
several commands using the ";" such as:
ls -lFR>report;cat bozo>>report;grep -i "last:" report>grep.rep
For DOS systems, well, too bad...
If you want to execute a program, then you can enter the command as
such:
program {parameters} <CR><LF>
(The <CR><LF> combination is for DOS.)
Therefore to execute a shell (on DOS or Unix or whatever), then
your command would be:
sh scripttorun
MPModem send routine will send this command to the receiver, and
providing the receiver is allowed to and can perform the above
command, it will do so and end the current Zmodem trabsfer session.
So feasibly you could send the file "scripttorun" and providing
this download goes to the current directory in which MPModem
resides, you could then send the above command and execute it.
The maximum length of a command is 1024 bytes (including the CR/LF
combination).
An example command file is included and a dummy script program
called "SH.EXE" are included. It doesn't do much but show you how
commands can work. Put the SH.EXE program in your MPModem directory
and enable commands via the configuration program. Then get the
sender to send the command. If you are using MPModem to send the
command, then get them to place the MPMODEM.CMD file in the MPModem
directory and specify a command line like:
"mpmodem -sz -p? -b???? -x".
MPModem v1.60 Copyright (C) M. Jose Page 56
11.0 Acknowledgements
----------------------
The author wishes to acknowledge the following peoples' work:
Gary S. Brown - The 32 bit CRC code.
Joe Campbell - "C Programmer's Guide to Serial
Communications", an excellent reference
book written clearly but perhaps not
concisely. A good starting text.
Ward Christensen - Creator of Modem.Asm (1977) & Ymodem.
Chuck Forsberg - The creator of Public Domain Zmodem (under
a Telnet contract).
Keith Petersen - Adapted Modem.Asm for RCPM (Remote CP/M)
systems and called it Xmodem.
All products mentioned in this documentation are trademarks of or
copyright to their respective owners.